[% setvar title The Perl 6 summary for the week ending 20030223 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 summary for the week ending 20030223'></a><h1>The Perl 6 summary for the week ending 20030223</h1>
<p>Another week, another Perl 6 Summary, in which you'll find gratuitous
mentions of Leon Brocard, awed descriptions of what Leopold
T&ouml;tsch got up to and maybe even a summary of what's been
happening in Perl 6 design and development.</p>
<p>Kicking off with perl6-internals as usual.</p>
<a name='Strings and header reuse'></a><h2>Strings and header reuse</h2>
<p>Dan responded to prompting from Leo T&ouml;tsch about the use and
reuse of string headers. The problem is that most of the string
functions that produce modified strings do it in new string headers;
there's no way of reusing existing string headers. This can end up
generating loads of garbage. Dan's going through the various string
handling ops and PMC interfaces working out what needs to do what, and
documenting them, as well as adding in versions of the ops that take
their destination string headers as an argument. Dan hopes that 'we
can make the changes quickly and get this out of the way once and for
all', leading Robert Spier to mutter something about 'famous last
words'.</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f01ba76a0489bfb@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='PXS help'></a><h2>PXS help</h2>
<!-- POD_ERROR: unterminated F<...> at line 29 in file list-summaries/2003/p6summary.2003-02-23.pod -->
<p>Tupshin Harper has been trying to use an XML parser from within Parrot
and started off by looking at the PXS example (in <b><i>examples/pxs) but
had problems following the instructions given there as his compiler
spat out errors by the bucket load. Leo T&ouml;tsch thought that PXS
was probably deprecated and the native call interface (NCI) was the
thing to use. Being Leo, he provided a port of the PXS Qt example to
NCI. Although PXS appears to be out of sync with the parrot core,
nobody was entirely sure whether it should be removed.</i></b></p>
<p><a href='http://groups.google.com/groups?threadm=3E5186AB.2030604@tupshin.com' target='_blank'>groups.google.com</a></p>
<a name='Bit rot in parrot/language/*'></a><h2>Bit rot in <b><i>parrot/language/*</i></b></h2>
<p>Tupshin Harper had some problems with some of the language examples
not working well with the most recent versions of Parrot. Leo
T&ouml;tsch addressed most of the issues he raised, but there are
definitely issues with the interpreter and the languages getting out
of sync.</p>
<p><a href='http://groups.google.com/groups?threadm=3E52078F.9060807@tupshin.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3E523381.6080109@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Macros in IMCC (part 2)'></a><h2>Macros in IMCC (part 2)</h2>
<p>J&uuml;rgen B&ouml;mmels extended the macro support in IMCC,
implementing <code>.constant</code> and adding some docs. The patch was promptly
applied.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=21277' target='_blank'>rt.perl.org</a></p>
<a name='[RFD] IMCC calling conventions'></a><h2>[RFD] IMCC calling conventions</h2>
<p>Leo T&ouml;tsch posted an RFD covering his understanding of the
various calling conventions that IMCC would have to deal with which
sparked some discussion. I'm now confused as to whether function calls
in Parrot will be caller saves, callee saves, or some unholy mixture
of the two.</p>
<p><a href='http://groups.google.com/groups?threadm=3E521993.5050700@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Parrot performance vs the good, the bad and the ugly'></a><h2>Parrot performance vs the good, the bad and the ugly</h2>
<p>Tupshin Harper decided to port <b><i>primes.pasm</i></b> to C and Perl 5 to
compare results. Parrot came out very quick indeed. (Close to C). For
bonus points he then took a python primes algorithm that had been
ported to C and ported that to Parrot as well. In full on, all stops
pulled out, knobs turned to 11 mode, Parrot came in at about 50%
slower than C and around 14 times faster than Python. There was some
muttering about the demo being rigged. However, Jim Meyer redid the
Perl and Python implementations to use a loop that duplicated the
algorithm used in <b><i>primes.pasm</i></b> and, whilst it improved their
performance somewhat, Parrot was still substantially faster.</p>
<p>This probably won't be the test that's run when Dan and Guido face the
possibility of custard pies at 10 paces or whatever the performance
challenge stake stands at now.</p>
<p><a href='http://groups.google.com/groups?threadm=3E52211C.1070907@tupshin.com' target='_blank'>groups.google.com</a></p>
<a name='Mmm... spaceships...'></a><h2>Mmm... spaceships...</h2>
<p>Leon Brocard patched <b><i>examples/assembly/life.pasm</i></b> to use a small
spaceship as its starting pattern. Apparently because it 'can provide
hours of enjoyment at conferences if projected onto a big screen while
answering parrot questions.' Nobody thought to ask him how a spaceship
was going to answer Parrot questions, but Leo T&ouml;tsch applied the
patch.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-21301-52439.16.4792168417894@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Using IMCC as JIT optimizer'></a><h2>Using IMCC as JIT optimizer</h2>
<p>Apparently, Leo T&ouml;tsch finds it unbearable that 'optimized
compiled C is still faster than parrot -j' so he's been experimenting
with adding smarts to IMCC, making it add hardware register allocation
hints to its emitted bytecode. Sean O'Rourke liked the basic idea, but
reckoned that the information generated by IMCC should really be
platform-independent, suggesting that it'd be okay to pass a control
flow graph to the JIT, but that hardware register allocation for a
specific number of registers would iffy. He suggested that another
option would be for IMCC to 'just rank the Parrot registers in order
of decreasing spill cost', then the JIT could just move the most
important parrot registers into architectural registers.</p>
<p>Dan thought the idea was interesting too, but worried that the JIT
might spend more time optimizing code than it could possibly gain from
the optimization. The discussion got more than a little technical
after this. I'm afraid I'm a bear of little brain when it comes to
this sort of magic, so you'll have to read the whole thread if you're
interested in the details.</p>
<p>The response was pretty positive throughout the discussion, so Leo
went ahead and implemented it. The new, improved version shaved
slightly more than a tenth of a second from the primes.pasm runtime
(not a great percentage win, but the total runtime includes the
compilation time)</p>
<p><a href='http://groups.google.com/groups?threadm=3E54B776.1080508@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3E58EC12.7090407@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='invoke'></a><h2><code>invoke</code></h2>
<p>Steve Fink is bothered by the <code>invoke</code> op because it operates
implicitly on P0. He wants to replace it with a new version that takes
a PMC argument. Leo T&ouml;tsch is less bothered by the implicit
behaviour of the op, but would like to see an additional <code>invoke_p</code>
op, which would take a single PMC argument. So Steve implemented it,
but hit a couple of snags. I'm not quite sure whether these have been
overcome yet.</p>
<p><a href='http://groups.google.com/groups?threadm=20030220182024.GB21582@foxglove' target='_blank'>groups.google.com</a></p>
<a name='Problems with Configure.pl --cgoto=0'></a><h2>Problems with <code>Configure.pl --cgoto=0</code></h2>
<p>Nicholas Clark was unable to build Parrot with computed gotos turned
off. Simon Glover offered a simple patch that fixed Nick's
problem. Leo T&ouml;tsch talked about the different reasons for not
building a computed goto core, which depends on both the compiler's
capabilities and the user's choices. This led to a discussion of which
cores were now obsolete. Leo believes that the simple Computed Goto
and Prederef cores have been obsoleted by the CGP core (Computed Goto
Prederefed). Nick thought we should continue to ship code for all the
cores, and ensure that the config system is flexible enough to let
anyone build any arbitrary combination of cores, which convinced
Leo. Dan suggested that, once we'd done this we should revamp the
Tinderbox system to run tests on all the core types.</p>
<p><a href='http://groups.google.com/groups?threadm=20030220213957.GC281@Bagpuss.unfortu.net' target='_blank'>groups.google.com</a></p>
<a name='Non-inline text in parrot assembly'></a><h2>Non-inline text in parrot assembly</h2>
<p>Tupshin Harper wondered if there were any plans for Parrot to support
a distinct <code>.string</code> asm section. Leo T&ouml;tsch pointed to
<code>.constant</code> (in PASM) and <code>.const</code> (in IMCC) as ways of keeping
strings visually together. Tupshin realised he'd missed a chunk of
documentation (<code>perldoc assemble.pl</code> for anyone else who hasn't read
it) which he thinks should probably be moved into
<b><i>docs/parrot_assembly.pod</i></b> or somewhere similar.</p>
<p><a href='http://groups.google.com/groups?threadm=3E574520.3040203@tupshin.com' target='_blank'>groups.google.com</a></p>
<a name='Access to partial registers?'></a><h2>Access to partial registers?</h2>
<p>Tupshin Harper wondered if it was possible and/or meaningful to read
and write from a part of a register (eg. a single word) in
PASM. Answer: Not at the moment, what do you want? We can always add
an <b><i>intreg.ops</i></b> set.</p>
<p><a href='http://groups.google.com/groups?threadm=3E5837F6.90705@tupshin.com' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>Things were, once more quiet (all of 16 messages). I think we're all
awaiting the coming of the Prophet Zarquon (or possibly the next
Apocalypse, whichever comes soonest.)</p>
<a name='Arrays, lists, referencing'></a><h2>Arrays, lists, referencing</h2>
<p>David Storrs suggested some possible semantics for <code>(4, 1, 2) + 7</code>,
noting that he doesn't like the Perl5's current behaviour (evaluates
to 9). Michael Lazzaro thinks it should evaluate to 10 (length of the
list + 7) or possibly throw a syntax error. This then morphed into a
discussion of pass by value, pass by reference and pass by constant
reference, which Allison Randal told us would be addressed in the
upcoming Apocalypse 6.</p>
<p><a href='http://groups.google.com/groups?threadm=20030215084750.A80337@megazone.bigpanda.com' target='_blank'>groups.google.com</a></p>
<a name='Err...'></a><h2>Err...</h2>
<a name='That's it'></a><h2>That's it</h2>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>Mmm... the comfy chair... it's the only place to write a summary
in. Especially when you're plied with lashings of Earl Grey tea and
entertained by the antics of a couple of adolescent cats. Things could
be lots worse.</p>
<p>I'd like to apologize to Danny O'Brien for last weeks mention of 'a
Brainf*ck compiler, in Brainf*ck, for the Brainf*ck interpreter
supplied with Parrot, a virtual machine named after a joke, written
for a language that doesn't yet exist.' Apparently this sprained
Danny's head. And I extend similar apologies to anyone else whose head
was sprained by that concept.</p>
<p>The American Odyssey web page is still more of a beautiful idea than an
actual link you can click. Hopefully it'll spring into existence
before we set off, but I wouldn't bet on it.</p>
<p>Aspell is, once more, the weapon of proofreading choice.</p>
<p>If you  appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, job offers or his and hers Mini Coopers to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, job offers or his and hers Mini Coopers
to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
<p>This week's summary was again sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>.</p>
</div>
